|
|
| Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Amida Ta
German Mining and Manufacture Corp.
   |
Posted - 2008.10.21 12:58:00 -
[1]
I don't know HOW many posts I have written to please use WebServices instead of that dreadful REST XML. And NOW where we have API-Interface Projects you think about using WebServices?
You sure know how to keep your community busy *g*.
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.10.29 21:42:00 -
[2]
Sorry, but I'm of the complete opposite opionion. Retrieving XML files via HTTP sure is available for basically every platform in existance. But other than that there are absolutely no other reasons to have it.
Lets look at what we got:
A (meanwhile) quite large sets of APIs all producing completely non-standard and custom XML documents. Also some seem to have some sort of structuring that structure is not standardized either and differs slightly from file to file.
In consequence if you want to use the API today (and you do not just want to look at XML) your only chance is to HAND-Parse every type of XML-Response. This is completely insane.
My library does that and it's quite large. And there are still more problems. There is no versioning for the XML-Files. Not long ago one of my apps broke because the XML was changed in a way that could not be detected by the parser...
And parsing XML is not a simple thing, even with libraries it requires substantial amount of boilerplate code.
With WebServices you can autogenerate ALL of that boilerplate code. All responses are strictly standardized. It is 'impossible' to have structural error (like the ones we have now). Granted, not every development environment offers full support for that, but those that do make the usage of one of the APIs a matter of *seconds* even for the huge API Interfaces (like Charactersheet).
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.10.31 15:18:00 -
[3]
 Originally by: Tonto Auri
Originally by: Amida Ta
Sorry, but I'm of the complete opposite opionion. Retrieving XML files via HTTP sure is available for basically every platform in existance. But other than that there are absolutely no other reasons to have it.
There's absolutely no reasons to not have it.
XML HTTP feeds supported widely, in many ways, you could even directly embed your character sheet in Excel book.
No I couldn't. The reason is very simple: Plain XML does not offer enough information to correctly do it (It might for some but in general it doesn't). If I tried to put it in Excel e.g. all decimal values would be wrong because by german Excel expects a ',' as decimal separator and would just ignore the existing '.'.
Originally by: Tonto Auri
Quote:
Lets look at what we got:
A (meanwhile) quite large sets of APIs all producing completely non-standard and custom XML documents.
XML itself is a standard, and it is VERY strict one.
Sure but the structure of the concrete APIs is completely non-standardized. By default in XML everything is text, but for a lot of reasons (e.g. see above) that is not sufficient. Sure having a XSD/DTD for the current XML-files would help a lot, too. But with a web-service you get that guaranteed - and for free.
Originally by: Tonto Auri
Quote:
Also some seem to have some sort of structuring that structure is not standardized either and differs slightly from file to file.
Minor and arguable issue.
If you want to parse that for an application it is surely neither minor nor arguable. For SOME usecases you are of course correct.
Originally by: Tonto Auri
Quote:
In consequence if you want to use the API today (and you do not just want to look at XML) your only chance is to HAND-Parse every type of XML-Response. This is completely insane.
There's tons of programs that doing it for you, either MS IE offers XML structure browser.
Moot point, especially with "insane" exaggeration.
Imho it's not really an option for most people to look at XML in plane text. Even when node-structured plain text.
Originally by: Tonto Auri
Quote:
My library does that and it's quite large. And there are still more problems. There is no versioning for the XML-Files. Not long ago one of my apps broke because the XML was changed in a way that could not be detected by the parser...
If that was change in API format and you were not updated your program, it is your fault.
And why? If the API had a standard way to tell that It had changed then my app could just have detected that and told that the current API is incompatible. THEN it would have been my fault. But in the current situation with no versioning there is just no viable programmatic way to detect any possible changes.
Originally by: Tonto Auri
Quote:
And parsing XML is not a simple thing, even with libraries it requires substantial amount of boilerplate code.
Depends on library you are using, it could be as simple as one visible page of code to break it all into usable structure.
Or tons of unreadable crap of poorly connected chunks of hand magic.
Well I have been thinking about OO languages here. Obviously just getting the structure of an XML document is not really much of an efford (thats what XML is good for). Connecting to other backends (like OO) however is.
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.11.09 10:21:00 -
[4]
Originally by: Dragonaire
Could make web services a wrapper for XML and get the same thing done 
No you can't. Web Services contain lots of data an metadata that is not available in the current XML form. You cannot just generate the metadata out of nowhere.
The other way around might work: You can strip them of that metadata to produce the XML files.
|
|
|
| |
|